Strategy Pattern

Assembled by GimunLee

Goal

• Strategy Pattern의 개념을 알 수 있다.
• Strategy Pattern의 사용 이점에 대해 설명할 수 있다.
• Strategy Pattern을 사용할 수 있다.

What is Strategy Pattern?

스트래티지 패턴(Strategy Pattern)에서는 알고리즘군을 정의하고 각각을 캡슐화 하여 교환해서 사용할 수 있도록 만듭니다. 스트래티지 패턴(Strategy Pattern)을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경 할 수 있습니다.

이번 장에서는 주어진 요구사항을 구현하면서 Strategy Pattern의 사용 이점과 구현 방법에 대해 알아보도록 하겠습니다.

요구사항

고객 A가 오리 연못 시뮬레이션 게임을 만들어달라고 요구하고 있습니다.

고객 A : 'SimpleUDuck'이라는 오리 연못 시뮬레이션 게임을 만들어주세요. 이 게임에서는 헤엄도 치고 꽥꽥거리는 소리도 내는 매우 다양한 오리 종류를 보여줘야합니다.

여러분이라면 'SimpleUDuck' 애플리케이션을 어떻게 구현하실 것 같나요?

표준적인 객체지향 기법 사용하기

이 의뢰를 맡은 개발자를 조(Joe)라고 해보겠습니다. 조는 표준적인 객체지향 기법을 사용하여 Duck이라는 수퍼클래스를 만든 다음, 그 클래스를 확장하여 다른 모든 종류의 오리를 만들어보았습니다.

여러분들이 보기에 어떤가요? 그다지 문제가 없어보이시나요? 이때, 고객 A는 추가 요구사항을 말합니다.

고객 A : 오리가 헤엄만 치는게 아니라 날아다녔으면 좋겠어요!

개발자 조는 Duck이라는 수퍼클래스에 fly()라는 함수만 구현하면 되지! 라며 아래와 같이 프로그램을 개발하게 됩니다.

그런데 고객 A는 화가나 조에게 화를 냈습니다. 해당 프로그램을 데모할 때, 고무 장난감 오리가 날라다녔다면서 말이죠.

문제는 Duck이라는 수퍼클래스에 fly()가 추가되면서 일부 서브클래스에는 적합하지 않은 행동이 전부 추가된 것입니다. 상속을 잘 활용하여 코드를 재사용할 수 있었다고 생각했지만, 실제 코드에서는 심각한 오류를 발생시킬 수 있다는 것을 간과한 것입니다.

조는 아래와 같이 RubberDuck 클래스에 fly()를 오버라이드해서 아무것도 안하게 구현해봅니다.

이때, 만약 울지도 날지도 못하는 나무로 된 가짜 오리를 추가하게 되면 어떻게 해야할까요? 아래와 같이 quack()과 fly()에 아무것도 하지 않도록 구현하면 될까요?

위와 같이 개발한다면 수퍼클래스의 함수가 필요없는 서브클래스를 만들때 불필요한 소스코드를 작성해야합니다. 개발자 조는 수퍼클래스에 있는 함수를 인터페이스로 아래와 같이 구현해보기로 했습니다.

이러한 인터페이스 방식은 Flyable이라는 인터페이스를 만들면 '날 수 있는' 행동에 대한 코드 재사용을 전혀 기대할 수 없게 되므로, 코드 관리면에서 커다란 문제점이 생기게 됩니다. (인터페이스에서는 구현체만 만들수 있습니다.)

개발자 조는 상속(클래스, 인터페이스)을 사용하는 것이 그리 성공적이지 못하다는 것을 이제 확실히 알았습니다. 서브클래스마다 오리의 행동이 바뀔 수 있는데도 모든 서브클래스에서 한 행동을 사용하도록 하는 것은 그리 올바르지 못하기 때문입니다.

인터페이스를 사용하는 방법은 처음에는 괜찮아보였지만, 자바 인터페이스에는 구현된 코드가 전혀 들어가지 않기 때문에 코드 재사용을 할 수 없다는 문제점이 있었습니다. 즉 행동을 바꿀 때마다 그 행동이 정의되어 있는 서로 다른 서브클래스들을 전부 찾아서 코드를 일일이 고쳐야 합니다.

그럼 대체 어떻게 해야할까요? 이때 사용하는 것이 Strategy Pattern 입니다. 무엇인지는 모르겠지만, 어떤 상황에서 사용해야하는지 감이 오고 계실겁니다. 이제 본격적으로 알아보도록 하겠습니다.

들어가기 전에

우선 Strategy Pattern을 사용하기 위해서는 몇가지 디자인 원칙을 알아야할 필요가 있습니다.

디자인 원칙 1. 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다.

즉, 코드에 새로운 요구사항이 있을 때마다 바뀌는 부분이 있다면, 그 행동을 바뀌지 않는 다른 부분으로부터 골라내서 분리해야 한다는 것을 알 수 있습니다.

이 원칙은 다음과 같은 식으로 생각할 수도 있습니다.

바뀌는 부분은 따로 뽑아서 캡슐화 시킨다. 그렇게 하면 나중에 바뀌지 않는 부분에는 영향을 미치지 않은 채로 그 부분만 고치거나 확장할 수 있다.

위 개념은 매우 간단하지만 다른 모든 디자인 패턴의 기반을 이루는 원칙입니다.

Strategy Pattern 사용하기

1. 바뀌는 부분과 그렇지 않은 부분 분리하기

지금까지 살펴본 바로 fly() 문제를 제외하면 Duck 클래스는 잘 작동하고 있으며, 나머지 부분은 자주 달라지거나 바뀌지 않습니다. 그러므로 몇가지 자잘한 변경 사항을 제외하면 Duck 클래스는 그대로 두는 게 좋습니다.

변화하는 부분 과 그대로 있는 부분 을 분리하려면 (Duck하고는 완전히 별개로) 두 개의 클래스 집합을 만들어야 합니다. 하나는 나는 것과 관련된 집합이고, 다른 하나는 꽥꽥거리는 것과 관련된 부분입니다. 각 클래스 집합에는 각각의 행동을 구현한 것을 전부 집어넣습니다.

예를 들어, 꽥꽥거리는 것을 구현하는 클래스를 하나 만들고, 빽빽거리는 것을 구현하는 클래스를 하나 만들고, 아무 소리도 내지 않는 것을 구현하는 클래스를 하나 만드는 식으로 말입니다.

**그렇다면 나는 행동과 꽥꽥거리는 행동을 구현하는 클래스 집합은 어떻게 디자인해야할까요? **

우선 최대한 유연한 클래스 집합을 만드는 것이 좋습니다. 애초에 이런 문제에 말려든 게 오리의 행동과 관련된 유연성이기 때문입니다.

예를 들어, MallardDuck 인스턴스를 새로 만들고 특정 형식의 나는 행동으로 초기화하는 것도 좋은 방법일 것입니다. 그리고 오리의 행동을 동적으로 바꿀 수 있으면 더 좋을 것 같습니다. 즉 Duck 클래스에 행동과 관련된 세터(setter) 메소드를 포함시켜서 프로그램 실행중에도 MallardDuck의 나는 행동을 바꿀 수 있도록 하면 좋을 것입니다.

일단 이렇게 목표를 정해놓은 다음, 다음과 같은 두 번째 디자인 원칙을 살펴보겠습니다.

2. 구현이 아닌 인터페이스에 맞춰서 프로그래밍하기

디자인 원칙 2. 구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.

각 행동은 인터페이스로 표현하고 행동을 구현할 때 인터페이스를 구현하도록 합니다. 이제 나는 행동은 이제 Duck 클래스에서 구현하지 않습니다. 대신 특정 행동만을 목적으로 하는 클래스의 집합을 만듭니다.

행동 인터페이스는 Duck 클래스가 아닌, 방금 설명한 행동 클래스에서 구현합니다. 새로운 디자인을 사용하면 Duck의 서브클래스에서는 인터페이스로 표현되는 행동을 사용하게 됩니다. 따라서 행동을 실제로 구현한 것은 Duck 서브클래스에 국한되지 않습니다.

이런식으로 디자인하면 다른 형식의 객체에서도 나는 행동을 재 사용할 수 있습니다. 그리고 기존의 행동 클래스를 수정하거나 날아다니는 행동을 사용하는 Duck 클래스를 전혀 건드리지 않고도 새로운 행동을 추가할 수 있습니다.

즉, 중요한 것은 이제 Duck에서 나는 행동을 Duck 클래스에서 정의한 메소드를 써서 구현하지 않고 다른 클래스에 위임한다는 것입니다.

3. Duck 클래스에 나는 행동 통합하기

1. 우선 Duck 클래스에 flyBehavior라는 인터페이스 형식의 인스턴스 변수를 추가할 것입니다.

   

   각 Duck 객체에서는 실행 시에 이 변수에 특정 행동 형식(FlyWithWings, FlyNoWay..)에 대한 레퍼런스를 다형적으로 설정합니다.

2. 그 다음 performFly()를 구현해보겠습니다.

   public class Duck {
       // FlyBehavior 인터페이스를 구현하는 레퍼런스
       FlyBehavior flyBehavior;
       
       // flyBehavior로 참조되는 객체에 그 행동을 위임
       public void performFly(){
           flyBehavior.fly();
       }
   }
   

   지금 이 코드에서는 객체의 종류에는 전혀 신경 쓸 필요가 없습니다. fly()를 실행시킬 줄 안다는 것이 중요할 뿐입니다.

3. flyBehavior 인스턴스 변수를 설정하는 MallardDuck 클래스를 만들어봅니다.

public class MallardDuck extends Duck {
    public MallardDuck(){
        flyBehavior = new FlyWithWings();
    }
    public void display() {
        System.out.println("저는 물오리입니다.");
    }
}

MallardDuck 생성자에서는 flyBehavior 인스턴스 변수에 FlyWithWings 형식의 인스턴스를 만들어서 대입합니다.

각 오리에는 FlyBehavior가 있으며, 나는 행동을 위임 받습니다. 클래스를 이런 식으로 합치는 것을 구성(Composition)을 이용하는 것이라고 부릅니다. 여기에 나와있는 Duck 클래스에서는 행동을 상속받는 대신, 올바른 행동 객체로 구성됨으로써 행동을 부여받게 됩니다.

4. "A는 B이다" 보다 "A에는 B가 있다"가 나을 수도 있습니다.

디자인 원칙 3. 상속보다는 구성을 활용한다.

지금까지 봐 왔던 것처럼, 구성을 이용하여 시스템을 만들면 유연성을 쿠게 향상시킬 수 있습니다. 단순히 알고리즘군을 별도의 클래스의 집합으로 캡슐화할 수 있도록 만들어주는 것 뿐 아니라, 구성요소로 사용하는 객체에서 올바른 행동 인터페이스를 구현하기만 하면 실행시에 해동을 바꿀 수도 있게 해줍니다.

References

• Head First Design Patterns
• 스트래티지 패턴
• Strategy Pattern | Head First Design Patterns